home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pppext-lcpext-01.txt < prev    next >
Text File  |  1993-03-21  |  29KB  |  1,158 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            Simpson
  8. Internet Draft                                                Daydreamer
  9. expires in six months                                         March 1993
  10.  
  11.  
  12.  
  13.                            PPP LCP Extensions
  14.  
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This memo is the product of the Point-to-Point Protocol Working Group
  20.    of the Internet Engineering Task Force (IETF).  Comments on this memo
  21.    should be submitted to the ietf-ppp@ucdavis.edu mailing list.
  22.  
  23.    Distribution of this memo is unlimited.
  24.  
  25.    This document is an Internet Draft.  Internet Drafts are working
  26.    documents of the Internet Engineering Task Force (IETF), its Areas,
  27.    and its Working Groups.  Note that other groups may also distribute
  28.    working documents as Internet Drafts.  Internet Drafts are draft
  29.    documents valid for a maximum of six months.  Internet Drafts may be
  30.    updated, replaced, or obsoleted by other documents at any time.  It
  31.    is not appropriate to use Internet Drafts as reference material or to
  32.    cite them other than as a ``working draft'' or ``work in progress.''
  33.    Please check the 1id-abstracts.txt listing contained in the
  34.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  35.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  36.    current status of any Internet Draft.
  37.  
  38. Abstract
  39.  
  40.    The Point-to-Point Protocol (PPP) [1] provides a standard method of
  41.    encapsulating Network Layer protocol information over point-to-point
  42.    links.  PPP also defines an extensible Link Control Protocol.
  43.  
  44.    This document defines several additional LCP features which have been
  45.    suggested over the past year.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Simpson                  expires in six months                  [Page i]
  59. DRAFT                      PPP LCP extensions                 March 1993
  60.  
  61.  
  62. 1.  Additional LCP Packets
  63.  
  64. The Packet format and basic facilities are already defined for LCP [1].
  65.  
  66. Up-to-date values of the LCP Code field are specified in the most recent
  67. "Assigned Numbers" RFC [2].  This document concerns the following
  68. values:
  69.  
  70.    13      Time-Remaining
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Simpson                  expires in six months                  [Page 1]
  114. DRAFT                      PPP LCP extensions                 March 1993
  115.  
  116.  
  117. 1.1.  Time-Remaining
  118.  
  119.    Description
  120.  
  121.       This Code provides a mechanism for notifying the peer of the time
  122.       remaining in this session.
  123.  
  124.       The nature of this information is advisory only.  It is intended
  125.       that only one side of the connection will send this packet
  126.       (generally a "network access server").  The session is concluded
  127.       by the Terminate-Request packet.
  128.  
  129.          Implementation Note: This notification is defined as a separate
  130.          LCP Code, rather than a Configuration-Option, in order that
  131.          changes and warning messages may occur dynamically during the
  132.          session, and that the information might be determined after
  133.          Authentication has occurred.  Typically, this packet is sent at
  134.          the beginning of a session, and at regular intervals throughout
  135.          the session, particularly near the end of the session.
  136.  
  137.    A summary of the Time-Remaining packet format is shown below.  The
  138.    fields are transmitted from left to right.
  139.  
  140.     0                   1                   2                   3
  141.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  142.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  143.    |     Code      |  Identifier   |            Length             |
  144.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  145.    |                         Magic-Number                          |
  146.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  147.    |                       Seconds-Remaining                       |
  148.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  149.    | Message ...
  150.    +-+-+-+-+-+-+-+-+-+-+-+-+-
  151.  
  152.  
  153.    Code
  154.  
  155.       13 for Time-Remaining
  156.  
  157.    Identifier
  158.  
  159.       The Identifier field is one octet and is for use by the Time-
  160.       Remaining sender.
  161.  
  162.    Length
  163.  
  164.       >= 12
  165.  
  166.  
  167.  
  168. Simpson                  expires in six months                  [Page 2]
  169. DRAFT                      PPP LCP extensions                 March 1993
  170.  
  171.  
  172.    Seconds-Remaining
  173.  
  174.       The Seconds-Remaining field is four octets and indicates the
  175.       number of integral seconds remaining in this session.  This 32 bit
  176.       unsigned value is sent most significant octet first.  A value of
  177.       0xffffffff (all ones) represents no timeout, or "forever".
  178.  
  179.    Message
  180.  
  181.       The Message field is zero or more octets, and its contents are
  182.       implementation dependent.  It is intended to be human readable,
  183.       and MUST NOT affect operation of the protocol.  It is recommended
  184.       that the message contain displayable ASCII characters 32 through
  185.       126 decimal.  Mechanisms for extension to other character sets are
  186.       the topic of future research.  The size is determined from the
  187.       Length field.
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223. Simpson                  expires in six months                  [Page 3]
  224. DRAFT                      PPP LCP extensions                 March 1993
  225.  
  226.  
  227. 2.  Additional LCP Configuration Options
  228.  
  229. The Configuration Option format and basic options are already defined
  230. for LCP [1].
  231.  
  232. Up-to-date values of the LCP Option Type field are specified in the most
  233. recent "Assigned Numbers" RFC [2].  This document concerns the following
  234. values:
  235.  
  236.    9       FCS-Alternatives
  237.  
  238.    10      Self-Describing-Padding
  239.  
  240.    13      Callback
  241.  
  242.    15      Compound-Frames
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. Simpson                  expires in six months                  [Page 4]
  279. DRAFT                      PPP LCP extensions                 March 1993
  280.  
  281.  
  282. 2.1.  FCS-Alternatives
  283.  
  284.    Description
  285.  
  286.       This Configuration Option provides a method for an implementation
  287.       to specify another FCS format to be sent by the peer, or to
  288.       negotiate away the FCS altogether.
  289.  
  290.       This option is negotiated separately in each direction.  However,
  291.       it is not required that an implementation be capable of
  292.       concurrently generating a different FCS on each side of the link.
  293.  
  294.       The negotiated FCS values take effect only during Authentication
  295.       and Network-Layer Protocol phases.  Packets sent during any other
  296.       phase MUST contain the default FCS.
  297.  
  298.          Implementation Note: For most PPP links, the default FCS is the
  299.          16-bit FCS.  Some future high speed links may use another
  300.          format as the default FCS.
  301.  
  302.    A summary of the FCS-Alternatives Configuration Option format is
  303.    shown below.  The fields are transmitted from left to right.
  304.  
  305.  
  306.     0                   1                   2
  307.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  308.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  309.    |     Type      |    Length     |    Options    |
  310.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  311.  
  312.  
  313.    Type
  314.  
  315.       9
  316.  
  317.    Length
  318.  
  319.       3
  320.  
  321.    Options
  322.  
  323.       This field is one octet, and is comprised of the "logical or" of
  324.       the following values:
  325.  
  326.       1       Null FCS
  327.  
  328.       2       16-bit FCS
  329.  
  330.  
  331.  
  332.  
  333. Simpson                  expires in six months                  [Page 5]
  334. DRAFT                      PPP LCP extensions                 March 1993
  335.  
  336.  
  337.       4       32-bit FCS
  338.  
  339. 2.1.1.  LCP considerations
  340.  
  341.    The link can be subject to loss of state, and the LCP can re-
  342.    negotiate at any time.  When the LCP begins renegotiation or
  343.    termination, it is recommended that the LCP Configure-Request or
  344.    Terminate-Request packet be sent with the last negotiated FCS,
  345.    followed by a duplicate packet with the default FCS.  The packet
  346.    identifier SHOULD be incremented for each such packet.
  347.  
  348.    On receipt of a LCP Configure-Request or Terminate-Request packet,
  349.    the implementation MUST change to the default FCS for both
  350.    transmission and reception.  If the Request packet received does not
  351.    contain the default FCS, it MUST be silently discarded.
  352.  
  353.       Implementation Notes: The need to send two packets is only
  354.       necessary after the Alternative-FCS has already been negotiated.
  355.       It need not occur during state transitions when there is a natural
  356.       indication that the default FCS is in effect, such as the Down and
  357.       Up events.  This does not include the Ack-Sent state, since the
  358.       peer could mistakenly believe that the link has Opened.
  359.  
  360.       It is possible to send a single 48-bit FCS which is a combination
  361.       of the 16-bit and 32-bit FCS.  This may be sent instead of sending
  362.       the two packets described above.  We have not standardized this
  363.       procedure because of intellectual property concerns.
  364.  
  365.       If such a 48-bit FCS is used, it MUST only be used for LCP
  366.       packets.
  367.  
  368. 2.1.2.  Null FCS
  369.  
  370.    The Null FCS SHOULD only be used for those network-layer protocols
  371.    which have an end-to-end checksum available, such as TCP/IP, or
  372.    UDP/IP with the checksum enabled.  That is, the Null FCS option
  373.    SHOULD be negotiated together with another non-null FCS option in a
  374.    heterogeneous environment.
  375.  
  376.    When a configuration (LCP or NCP) or authentication packet is sent,
  377.    the FCS MUST be included.  When a configuration (LCP or NCP) or
  378.    authentication packet is received, the FCS MUST be verified.
  379.  
  380.    There are several cases to be considered:
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388. Simpson                  expires in six months                  [Page 6]
  389. DRAFT                      PPP LCP extensions                 March 1993
  390.  
  391.  
  392.    Null FCS alone
  393.  
  394.       This means that it is not necessary to check the FCS when a packet
  395.       is received.  Any FCS is treated as padding.
  396.  
  397.       Receipt of an Authentication packet would be discovered after
  398.       passing the packet to the demultiplexer.  Verification of the FCS
  399.       can easily be accomplished using one of the software algorithms
  400.       defined in LCP [1] (16-bit FCS) and Appendix A (32-bit FCS).
  401.  
  402.    Null FCS with another FCS, using software
  403.  
  404.       This is the same as the above case, except every packet is checked
  405.       (or not checked) after demultiplexing.
  406.  
  407.    Null FCS with another FCS, using hardware
  408.  
  409.       The packet MUST NOT be discarded until after demultiplexing.  The
  410.       incorrect FCS MUST be passed with the rest of the data.  A flag
  411.       would be passed with the packet indicating that it has not passed
  412.       the FCS check, and only those packets that require the FCS are
  413.       discarded.
  414.  
  415.    All three FCS forms (Null, 16 and 32) may be used concurrently on
  416.    different packets when using software.  That is probably not possible
  417.    with most current hardware.
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443. Simpson                  expires in six months                  [Page 7]
  444. DRAFT                      PPP LCP extensions                 March 1993
  445.  
  446.  
  447. 2.2.  Self-Describing-Padding
  448.  
  449.    Description
  450.  
  451.       This Configuration Option provides a method for an implementation
  452.       to indicate to the peer that it understands self-describing pads
  453.       when padding is added at the end of the PPP Information field.
  454.  
  455.       This option is most likely to be used when some protocols, such as
  456.       network-layer or compression protocols, are configured which
  457.       require detection and removal of any trailing padding.  Such
  458.       protocols are identified in their respective NCP documents.
  459.  
  460.       If the option is Rejected, the peer MUST NOT add any padding to
  461.       the identified protocols, but MAY add padding to other protocols.
  462.  
  463.       If the option is Ack'd, the peer MUST follow the procedures for
  464.       adding self-describing pads, but only to the specifically
  465.       identified protocols.  The peer is not required to add any padding
  466.       to other protocols.
  467.  
  468.          Implementation Notes: This is defined so that the Reject
  469.          handles either case where the peer does not generate self-
  470.          describing pads.  When the peer never generates padding, it may
  471.          safely Reject the option.  When the peer does not understand
  472.          the option, it also will not successfully configure a protocol
  473.          which requires the option.
  474.  
  475.          While some senders might only be capable of adding padding to
  476.          every protocol or not adding padding to any protocol, by design
  477.          the receiver need not examine protocols which do not need the
  478.          padding stripped.
  479.  
  480.          To avoid unnecessary configuration handshakes, an
  481.          implementation which generates padding, and has a protocol
  482.          configured which requires the padding to be known, SHOULD
  483.          include this Option in its Configure-Request, and SHOULD
  484.          Configure-Nak with this Option when it is not present in the
  485.          peer's Request.
  486.  
  487.       Each octet of self-describing pad contains the index of that
  488.       octet; that is, three pad octets would contain the values 1, 2, 3.
  489.       After removing the FCS, the final pad octet contains the number of
  490.       pad octets to remove.
  491.  
  492.       The maximum pad value is also negotiated.  Only the values 1
  493.       through the maximum are used.  When no padding would otherwise be
  494.       required, but the final octet of the PPP Information field
  495.  
  496.  
  497.  
  498. Simpson                  expires in six months                  [Page 8]
  499. DRAFT                      PPP LCP extensions                 March 1993
  500.  
  501.  
  502.       contains the values 1 through the maximum, at least one self-
  503.       describing pad octet MUST be added to the frame.  If the final
  504.       octet is distinguishable from a pad octet, no additional padding
  505.       is required.
  506.  
  507.          Implementation Notes: The first pad octet MUST contain the
  508.          value one (1) to prevent confusion with the Compound-Frames
  509.          option.
  510.  
  511.          If any of the pad octets contain an incorrect index value, the
  512.          entire frame SHOULD be silently discarded.  This is intended to
  513.          prevent confusion with the FCS-Alternatives option, but might
  514.          not be necessary in robust implementations.
  515.  
  516.          Since this option is intended to support compression protocols,
  517.          the maximum pad value is specified to limit the likelihood that
  518.          a frame may actually become longer.
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553. Simpson                  expires in six months                  [Page 9]
  554. DRAFT                      PPP LCP extensions                 March 1993
  555.  
  556.  
  557.    A summary of the Self-Describing-Padding Configuration Option format
  558.    is shown below.  The fields are transmitted from left to right.
  559.  
  560.  
  561.     0                   1                   2
  562.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  563.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  564.    |     Type      |    Length     |    Maximum    |
  565.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  566.  
  567.  
  568.    Type
  569.  
  570.       10
  571.  
  572.    Length
  573.  
  574.       3
  575.  
  576.    Maximum
  577.  
  578.       This field specifies the largest number of padding octets which
  579.       may be added to the frame.  The value may range from 1 to 255, but
  580.       values of 2, 4, or 8 are most likely.
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608. Simpson                  expires in six months                 [Page 10]
  609. DRAFT                      PPP LCP extensions                 March 1993
  610.  
  611.  
  612. 2.3.  Callback
  613.  
  614.    Description
  615.  
  616.       This Configuration Option provides a method for an implementation
  617.       to request a dial-up peer to call back.  This option might be used
  618.       for many diverse purposes, such as savings on toll charges.
  619.  
  620.       When Callback is successfully negotiated, the Authentication phase
  621.       proceeds directly to Termination phase.
  622.  
  623.          Implementation Note: A peer which agrees to this option SHOULD
  624.          request the Authentication-Protocol Configuration Option.  The
  625.          user information learned during authentication can be used to
  626.          determine the user location, or to limit a user to certain
  627.          locations, or merely to determine whom to bill for the service.
  628.  
  629.    A summary of the Callback Option format is shown below.  The fields
  630.    are transmitted from left to right.
  631.  
  632.     0                   1                   2                   3
  633.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  634.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  635.    |     Type      |    Length     |   Operation   |  Message ...
  636.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  637.  
  638.  
  639.    Type
  640.  
  641.       13
  642.  
  643.    Length
  644.  
  645.       >= 3
  646.  
  647.    Operation
  648.  
  649.       The Operation field is one octet and indicates the contents of the
  650.       Message field.
  651.  
  652.       0       location is determined by user authentication
  653.  
  654.       1       telephone number
  655.  
  656.       2       location identifier
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663. Simpson                  expires in six months                 [Page 11]
  664. DRAFT                      PPP LCP extensions                 March 1993
  665.  
  666.  
  667. Message
  668.  
  669.    The Message field is zero or more octets, and its general contents
  670.    are determined by the Operation field.  The actual format of the
  671.    information is site or application specific, and a robust
  672.    implementation should support many formats.  The size is determined
  673.    from the Length field.
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718. Simpson                  expires in six months                 [Page 12]
  719. DRAFT                      PPP LCP extensions                 March 1993
  720.  
  721.  
  722. 2.4.  Compound-Frames
  723.  
  724.    Description
  725.  
  726.       This Configuration Option provides a method for an implementation
  727.       to send multiple PPP Protocol datagrams within the same packet.
  728.       This option might be used for many diverse purposes, such as
  729.       savings on toll charges.
  730.  
  731.       Only those Protocols which have determinate lengths or integral
  732.       length fields may be aggregated into a compound frame.
  733.  
  734.       When Compound-Frames is successfully negotiated, the sender MAY
  735.       add additional datagrams to the same frame.  Each datagram is
  736.       immediately followed by another Protocol field, with its attendant
  737.       datagram.
  738.  
  739.       When padding is added to the end of the Information field, the
  740.       procedure described in Self-Describing-Padding is used.
  741.       Therefore, this option MUST be negotiated together with the Self-
  742.       Describing-Padding option.
  743.  
  744.       If the FCS-Alternatives option has been negotiated, and no self-
  745.       describing padding has been added, the final datagram MUST be
  746.       followed by a single octet containing the value one (1).
  747.  
  748.       On receipt, the first Protocol field is examined, and the datagram
  749.       is processed as usual.  For those datagrams which have a
  750.       determinate length, the remainder of the frame is returned to the
  751.       demultiplexor, and treated as a new Protocol field.  This
  752.       processing is complete when a datagram is processed which does not
  753.       have a determinate length, when the remainder of the frame is
  754.       empty, or when the Protocol field is determined to have a value of
  755.       one (1).
  756.  
  757.       The PPP Protocol value of one (1) is reserved as the Padding
  758.       Protocol.  Additional octets are removed as padding.
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773. Simpson                  expires in six months                 [Page 13]
  774. DRAFT                      PPP LCP extensions                 March 1993
  775.  
  776.  
  777.    A summary of the Compound-Frames Option format is shown below.  The
  778.    fields are transmitted from left to right.
  779.  
  780.     0                   1
  781.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  782.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  783.    |     Type      |    Length     |
  784.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  785.  
  786.  
  787.    Type
  788.  
  789.       15
  790.  
  791.    Length
  792.  
  793.       2
  794.  
  795. 2.4.1.  LCP considerations
  796.  
  797.    During initial negotiation, the Compound-Frames option can be used to
  798.    minimize the negotiation latency, and the number of packets
  799.    exchanged.
  800.  
  801.    The first LCP Configure-Request frame is sent as usual in a single
  802.    packet, including the Self-Describing-Padding and Compound-Frames
  803.    options.
  804.  
  805.    The peer SHOULD respond with a Configure-Ack, followed in a compound
  806.    frame by its LCP Configure-Request, and any NCP Configure-Requests
  807.    desired.
  808.  
  809.    Upon receipt, the local implementation SHOULD process the Configure-
  810.    Ack as usual.  Since the peer has agreed to send compound frames, the
  811.    implementation MUST examine the remainder of the packet for
  812.    additional datagrams.  If the peer also specified the Self-
  813.    Describing-Padding and Compound-Frames options, the local
  814.    implementation SHOULD retain its Configure-Ack, and further NCP
  815.    configuration packets SHOULD be added to the return packet.
  816.  
  817.    Together with the peer's final return packet, the minimum number of
  818.    packets to complete configuration is 4.
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828. Simpson                  expires in six months                 [Page 14]
  829. DRAFT                      PPP LCP extensions                 March 1993
  830.  
  831.  
  832. A.  Fast Frame Check Sequence (FCS) Implementation
  833.  
  834. A.1.  32-bit FCS Computation Method
  835.  
  836.    The following code provides a table lookup computation for
  837.    calculating the 32-bit Frame Check Sequence as data arrives at the
  838.    interface.
  839.  
  840.    /*
  841.     * u32 represents an unsigned 32-bit number.  Adjust the typedef for
  842.     * your hardware.
  843.     */
  844.    typedef unsigned long u32;
  845.  
  846.    static u32 fcstab_32[256] =
  847.       {
  848.       0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
  849.       0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
  850.       0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
  851.       0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
  852.       0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
  853.       0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
  854.       0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
  855.       0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
  856.       0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
  857.       0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
  858.       0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
  859.       0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
  860.       0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
  861.       0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
  862.       0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
  863.       0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
  864.       0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
  865.       0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
  866.       0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
  867.       0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
  868.       0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
  869.       0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
  870.       0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
  871.       0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
  872.       0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
  873.       0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
  874.       0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
  875.       0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
  876.       0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
  877.       0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
  878.       0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
  879.       0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
  880.  
  881.  
  882.  
  883. Simpson                  expires in six months                 [Page 15]
  884. DRAFT                      PPP LCP extensions                 March 1993
  885.  
  886.  
  887.       0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
  888.       0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
  889.       0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
  890.       0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
  891.       0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
  892.       0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
  893.       0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
  894.       0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
  895.       0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
  896.       0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
  897.       0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
  898.       0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
  899.       0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
  900.       0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
  901.       0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
  902.       0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
  903.       0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
  904.       0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
  905.       0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
  906.       0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
  907.       0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,
  908.       0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
  909.       0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
  910.       0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
  911.       0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
  912.       0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
  913.       0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
  914.       0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
  915.       0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
  916.       0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
  917.       0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
  918.       0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
  919.       };
  920.  
  921.    #define PPP_INITFCS32 0xffffffff   /* Initial FCS value */
  922.    #define PPP_GOODFCS32 0xfebb20e3   /* Good final FCS value */
  923.  
  924.    /*
  925.     * Calculate a new FCS given the current FCS and the new data.
  926.     */
  927.    u32 pppfcs32(fcs, cp, len)
  928.        register u32 fcs;
  929.        register unsigned char *cp;
  930.        register int len;
  931.        {
  932.        ASSERT(sizeof (u32) == 4);
  933.        ASSERT(((u32) -1) > 0);
  934.        while (len--)
  935.  
  936.  
  937.  
  938. Simpson                  expires in six months                 [Page 16]
  939. DRAFT                      PPP LCP extensions                 March 1993
  940.  
  941.  
  942.            fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]);
  943.  
  944.        return (fcs);
  945.        }
  946.  
  947.    main()
  948.        {
  949.        int len;
  950.        u32 fcs;
  951.        unsigned char buf[10];
  952.  
  953.        fcs = PPP_INITFCS32;
  954.  
  955.        while ((len = read(0, buf, sizeof buf)) > 0)
  956.            fcs = pppfcs32(fcs, buf, len);
  957.  
  958.        printf("0x%08X\n", fcs);
  959.        exit(0);
  960.        }
  961.  
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968.  
  969.  
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993. Simpson                  expires in six months                 [Page 17]
  994. DRAFT                      PPP LCP extensions                 March 1993
  995.  
  996.  
  997. Security Considerations
  998.  
  999.    Security issues are not discussed in this memo.
  1000.  
  1001.  
  1002. References
  1003.  
  1004.    [1]   Simpson, W.A., "The Point-to-Point Protocol (PPP)", RFC 1331,
  1005.          May 1992.
  1006.  
  1007.    [2]   Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC 1340,
  1008.          July 1992.
  1009.  
  1010.  
  1011. Acknowledgments
  1012.  
  1013.    Some of the original text for FCS-Alternatives was provided by Arthur
  1014.    Harvey (then of DEC).  The Null FCS was requested by Peter Honeyman
  1015.    (UMich).  The 32-bit FCS example code was provided by Karl Fox
  1016.    (Morning Star Technologies).
  1017.  
  1018.    Self-Describing-Padding was suggested and named by Fred Baker (ACC).
  1019.  
  1020.    Compound-Frames was suggested by Keith Sklower (Berkeley).
  1021.  
  1022.    The Time-Remaining feature was suggested by Brad Parker (then of
  1023.    Cayman).
  1024.  
  1025.  
  1026. Chair's Address
  1027.  
  1028.    The working group can be contacted via the current chair:
  1029.  
  1030.       Brian Lloyd
  1031.       B.P. Lloyd & Associates, Inc.
  1032.       3420 Sudbury Road
  1033.       Cameron Park, California 95682
  1034.  
  1035.       Phone: (916) 676-1147
  1036.  
  1037.       EMail: brian@lloyd.com
  1038.  
  1039.  
  1040. Author's Address
  1041.  
  1042.    Questions about this memo can also be directed to:
  1043.  
  1044.       William Allen Simpson
  1045.  
  1046.  
  1047.  
  1048. Simpson                  expires in six months                 [Page 18]
  1049. DRAFT                      PPP LCP extensions                 March 1993
  1050.  
  1051.  
  1052.       Daydreamer
  1053.       Computer Systems Consulting Services
  1054.       P O Box 6205
  1055.       East Lansing, MI  48826-6205
  1056.  
  1057.       EMail: Bill.Simpson@um.cc.umich.edu
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066.  
  1067.  
  1068.  
  1069.  
  1070.  
  1071.  
  1072.  
  1073.  
  1074.  
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103. Simpson                  expires in six months                 [Page 19]
  1104. DRAFT                      PPP LCP extensions                 March 1993
  1105.  
  1106.  
  1107.                            Table of Contents
  1108.  
  1109.  
  1110.      1.     Additional LCP Packets ................................    1
  1111.         1.1       Time-Remaining ..................................    2
  1112.  
  1113.      2.     Additional LCP Configuration Options ..................    4
  1114.         2.1       FCS-Alternatives ................................    5
  1115.            2.1.1  LCP considerations ..............................    6
  1116.            2.1.2  Null FCS ........................................    6
  1117.         2.2       Self-Describing-Padding .........................    8
  1118.         2.3       Callback ........................................   11
  1119.         2.4       Compound-Frames .................................   13
  1120.            2.4.1  LCP considerations ..............................   14
  1121.  
  1122.      APPENDICES ...................................................   15
  1123.  
  1124.      A.     Fast Frame Check Sequence (FCS) Implementation ........   15
  1125.         A.1       32-bit FCS Computation Method ...................   15
  1126.  
  1127.      SECURITY CONSIDERATIONS ......................................   18
  1128.  
  1129.      REFERENCES ...................................................   18
  1130.  
  1131.      ACKNOWLEDGEMENTS .............................................   18
  1132.  
  1133.      CHAIR'S ADDRESS ..............................................   18
  1134.  
  1135.      AUTHOR'S ADDRESS .............................................   18
  1136.  
  1137.  
  1138.  
  1139.  
  1140.  
  1141.  
  1142.  
  1143.  
  1144.  
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.